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DETAILED ACTION 
Response to Amendment 

Receipt of Applicant's Amendment, filed 09/27/2007 is acknowledged. 
Claims 1, 6, 8, 14, 20, and 28 have been amended and claim 4 has been cancelled. 

Claim Rejections - 35 USC § 101 

In view of the amendments provided on 09/27/2007, the 35 USC 101 rejections 
are hereby withdrawn. 

Claim Rejections - 35 USC §112 

Claims 1, 8, 14, and 20 are rejected under 35 U.S.C. 112, first paragraph, as 
failing to comply with the written description requirement. The claim(s) contains subject 
matter which was not described in the specification in such a way as to reasonably 
convey to one skilled in the relevant art that the inventor(s), at the time the application 
was filed, had possession of the claimed invention. "Displaying the workflow on a 
display" is not described in the specification. Appropriate correction is required. 

Claim Rejections • 35 USC § 103 

The following Is a quotation of 35 U.S.C. 103(a) which fomris the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
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the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
not commonly owned at the time a later invention was made in order for the examiner to 
consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 

Claims 1, 6-8, 10, 12-14. 16, 18-20, 22. 24-25 and 28-29 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ludwig etal. (Ludwig hereinafter) (U.S. PG 
Pub No. 2003/0004874) in view of Falk etal. (Falk hereinafter) (U. S. PG Pub No. 

2004/0111302). 

With respect to claim 1 , Ludwig teaches "A computer readable storage 
medium for storing an electronic data record, of an invoice, the electronic data 
record comprising" as the system may allow data to be entered for the following 
exemplary fields, which the system may be adapted to store as global information on 
the database: name, address, city, state, zip, country, phone, number, fax number, and 
maximum invoice amount allowed. The system may use the maximum invoice amount 



Application/Control Number: Page 4 

10/770,423 

Art Unit: 2166 

allowed field to establish a threshold for a maximum payment for a single invoice 
(Ludwig Paragraph 0075). 

"a data field for identification of a current state of the processing of the 
invoice wherein the current state is assigned by a user" as "Paid Through Another 
Source" may be provided by the system as an option for the biller system user to mark 
an invoice as closed by selecting desired invoices and clicking on the "Paid through 
another source" button. Once this occurs, the system may, for the invoices in question, 
update their audit trail to reflect that they were paid outside the system, and then 
change their status to closed (Ludwig Paragraph 0091 & 0130). Therefore the user is 
entering the current state "closed" by clicking on the button. Therefore the identification 
of the current invoice is that It is paid and closed. 

Further Ludwig teaches the filter area, the system may provide the following 
exemplary choices: by date (past due, eligible for discount, due within xxx days); and by 
status (paid invoices, adjusted invoices, unpaid invoices, paid through another source); 
and by payer (all payer, specific payer); and by attribute range between xxx and yyy 
(none, invoice numbers, store/location, purchase orders, purchase request number, 
invoice issue dates, dollar amount, bill of lading numbers, receiving location zipcodes, 
invoice aging) (Ludwig Paragraph 0080). These lines also teach the identification of 
the current state of the processing of the invoice. 

"the data field is used for starting a workflow which depends on the current 
state" as figures 6a-6c (Ludwig Figures 6a-6c). Figures 9a-9b teach a state dependent 
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workflow for the payment of an invoice. Figure 7c teaciies a state dependent worlcflow 
for adjustment of invoices. 

In figures 9a and 9b, the worlcflow for the payment is being initiated which is 
being dependent on the current state of the invoice, which is that the invoice is pending 
or due. 

"wherein the data field has a link to a table" as the system may linl< the status 
field to the invoice history page, at which the system may display a full status history for 
the selected invoice. By default, the system may display the following exemplary 
columns: payer name, invoice number, due date, status, net amount due, amount to 
pay, P.O. number, P.O. requisition number, store number, and select (Ludwig 
Paragraph 0092). 

"an instruction which depend on the current state and are automatically 
executable by a computer system" as (Ludwig Paragraph 0091 and 0045). In 
paragraph 0045 email notices are being sent automatically based on the current state of 
the invoice. 

Ludwig teaches the elements of claim 1 as noted above but does not explicitly 
discloses, "a state value table comprising the current state, and the state value 
table comprises an instruction which depend on the current state and are 
automatically executable by a computer system, and the workflow is displayed on 
a display to the user." 

However, Falk discloses, "a state value table comprising the current state, 
and the state value table comprises an instruction which depend on the current 
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state and are automatically executable by a computer system, and the workflow is 
displayed on a display to the user" as the main purposes of the workflow table is to 
allow the system to detemnine the next workflow state for a transactional folder based 
on Its current state and the completion of a given application function that alters that 
folder-i.e., the workflow state transition (Falk Paragraph 0589 and Figure 24). In 
addition to defining workflow state transitions, the workflow table implicitly defines 
workflow navigation as well. For any given transactional folder in a given state, the 
workflow table will define the application functions that are allowed to be performed in 
this state (Falk Paragraph 0591). Workflow state transitions are simple and 
determlnistic-the next workflow state is detemnlned simply by the current workflow state 
and the application function that was completed. However, in some cases, the 
transition can only be determined by inspecting other data elements within the 
transactional folder (Falk Paragraph 0603). Examiner interprets the workflow table as 
state value table comprising the current state. Workflow table/state value table further 
comprises executable functions that are allowed to be performed based on the current 
state. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because Falk's 
teaching would have allowed Ludwig to provide an automated system with the following 
capabilities unique to inter-organizatlonal business transaction processing: 1) a 
centralized network hub (web-based) that facilitates the inter-connection of various 
organizations and eliminates the proliferation of point-to-point interfaces, 2) an inter- 
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organizational workflow management system that provides a common framework for 
managing the state and status of all transactions within the system, 3) an inter- 
organizational transaction processing component that supports multiple organizations 
and their distinct relationship with each transaction while also ensuring the security and 
privacy of each organization's data, 4) a unified data model mechanism that allows 
common data elements to be exchanged while also supporting organization specific 
interface requirements, and 5) application specific data and functionality specific to the 
types of business transactions being processed. 

With respect to claim 6, Ludwig teaches "the computer readable storage medium 
for storing electronic data record of claim 1, wherein the electronic data record is 
at least partially accessible via the Internet and wherein the content of the data 
field for the current state or a data field for comments is editable via the Internet" 
as the system may pemnit information to be maintained and edited at this page, which 
the system may store as global information on the database (Ludwig Paragraph 0064). 
The present invention may be appropriately adapted to Include such communication 
functionality and Internet browsing ability (Ludwig Paragraph 0157). 

With respect to claim 7, Ludwig teaches "the computer readable storage 
medium for storing electronic data record of claim 1, wherein the state value table 
comprises one or more state dependent proposals for changing the current 

state" as the system may, for the invoices in question, update their audit trail to reflect 
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that they were paid outside the system, and then change their status to "Closed" 
(Ludwig Paragraph 0091 & Figure 9a). Figure 9a shows invoice status list reference 
numeral 909. 

Ludwig teaches the elements of claim 7 as noted above but does not explicitly 
discloses, "the state value table." 

However, Falk discloses, "the state value table" as the main purposes of the 
workflow table is to allow the system to determine the next workflow state for a 
transactional folder based on its current state and the completion of a given application 
function that alters that folder--i.e., the workflow state transition (Falk Paragraph 0589 
and Figure 24). Examiner interprets the workflow table as state value table comprising 
the current state. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because Falk's 
teaching would have allowed Ludwig to provide an automated system with the following 
capabilities unique to inter-organizational business transaction processing: 1) a 
centralized network hub (web-based) that facilitates the inter-connection of various 
organizations and eliminates the proliferation of point-to-point interfaces, 2) an inter- 
organizational workflow management system that provides a common framework for 
managing the state and status of all transactions within the system, 3) an inter- 
organizational transaction processing component that supports multiple organizations 
and their distinct relationship with each transaction while also ensuring the security and 
privacy of each organization's data, 4) a unified data model mechanism that allows 
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common data elements to be exchanged while also supporting organization specific 
interface requirements, and 5) application specific data and functionality specific to the 
types of business transactions being processed. 

With respect to claim 8, Ludwig teaches "a method for processing an 
electronic data record of an invoice, the electronic data record" as the system may 
allow data to be entered for the following exemplary fields, which the system may be 
adapted to store as global information on the database: name, address, city, state, zip, 
country, phone, number, fax number, and maximum invoice amount allowed. The 
system may use the maximum invoice amount allowed field to establish a threshold for 
a maximum payment for a single invoice (Ludwig Paragraph 0075) "comprising a 
data field for identification of a current state of the processing of the invoice, the 
method comprising" as "Paid Through Another Source" may be provided by the 
system as an option for the biller system user to mark an invoice as closed by selecting 
desired invoices and clicking on the "Paid through another source" button. Once this 
occurs, the system may, for the invoices in question, update their audit trail to reflect 
that they were paid outside the system, and then change their status to closed (Ludwig 
Paragraph 0091 & 0130). Therefore the user is entering the state "closed" by clicking 
on the button. Therefore the identification of the current invoice is that it is paid and 
closed. 

Further, Ludwig teaches the filter area, the system may provide the following 
exemplary choices: by date (past due, eligible for discount, due within xxx days); and by 
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status (paid invoices, adjusted invoices, unpaid invoices, paid through another source); 
and by payer (all payer, specific payer); and by attribute range between xxx and yyy 
(none, invoice numbers, store/location, purchase orders, purchase request number, 
invoice issue dates, dollar amount, bill of lading numbers, receiving location zipcodes, 
invoice aging) (Ludwig Paragraph 0080). These lines also teach the identification of 
the current state of the processing of the invoice. 

"displaying a dialogue for enabling the current state to be entered by a 
user and assigning the current sate entered by the user to the data field" as "Paid 
Through Another Source" may be provided by the system as an option for the biller 
system user to mark an invoice as closed by selecting desired invoices and clicking on 
the "Paid through another source" button. Once this occurs, the system may, for the 
invoices in question, update their audit trail to reflect that they were paid outside the 
system, and then change their status to closed (Ludwig Paragraph 0091 & 0130). 
Therefore the user is entering the state "closed" by clicking on the button. Therefore the 
identification of the current invoice is that it is paid and closed. 

"wherein the data field has a Vink to a table" as the system may link the status 
field to the invoice history page, at which the system may display a full status history for 
the selected invoice. By default, the system may display the following exemplary 
columns: payer name, invoice number, due date, status, net amount due, amount to 
pay, P.O. number, P.O. requisition number, store number, and select (Ludwig 
Paragraph 0092). 
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"an instruction wliich depend on tlie current state and are automatically 
executable by a computer system" as (Ludwig Paragraph 0091 and 0045). In 
paragraph 0045 email notices are being sent automatically based on the current state of 
the invoice. 

"starting a workflow which depends on the current state" as figures 6a-6c 
(Ludwig Figures 6a-6c). Figures 9a-9b teach a state dependent workflow for the 
payment of an invoice. Figure 7c teaches a state dependent workflow for adjustment of 
invoices. 

In figures 9a and 9b, the workflow for the payment is being initiated which is 
being dependent on the current state of the invoice, which is that the invoice is pending 
or due. 

Ludwig teaches the elements of claim 8 as noted above but does not explicitly 
discloses, "a state value table comprising the current state, and the state value 
table comprises an instruction which depend on the current state and are 
automatically executable by a computer system, and displaying the workflow on a 
display to the user." 

However, Falk discloses, "a state value table comprising the current state, 
and the state value table comprises an instruction which depend on the current 
state and are automatically executable by a computer system, and the workflow is 
displayed on a display to the user" as the main purposes of the workflow table is to 
allow the system to determine the next workflow state for a transactional folder based 
on its current state and the completion of a given application function that alters that 
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folder-i.e., the workflow state transition (Falk Paragraph 0589 and Figure 24). In 
addition to defining workflow state transitions, the workflow table implicitly defines 
workflow navigation as well. For any given transactional folder in a given state, the 
workflow table will define the application functions that are allowed to be performed in 
this state (Falk Paragraph 0591). Workflow state transitions are simple and 
determinlstic-the next workflow state is determined simply by the current workflow state 
and the application function that was completed. However, in some cases, the 
transition can only be determined by inspecting other data elements within the 
transactional folder (Falk Paragraph 0603). Examiner interprets the workflow table as 
state value table comprising the current state. Workflow table/state value table further 
comprises executable functions that are allowed to be performed based on the current 
state. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because Falk's 
teaching would have allowed Ludwig to provide an automated system with the following 
capabilities unique to inter-organizational business transaction processing: 1) a 
centralized network hub (web-based) that facilitates the inter-connection of various 
organizations and eliminates the proliferation of point-to-point interfaces, 2) an Inter- 
organizational workflow management system that provides a common framework for 
managing the state and status of all transactions within the system, 3) an inter- 
organizational transaction processing component that supports multiple organizations 
and their distinct relationship with each transaction while also ensuring the security and 
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privacy of each organization's data, 4) a unified data model mechanism that allows 
common data elements to be exchanged while also supporting organization specific 
interface requirements, and 5) application specific data and functionality specific to the 
types of business transactions being processed. 

With respect to claim 10, Ludwig teaches "the method of claim 8, further 
comprising: performing at least one of selecting, sorting, evaluating, and 
analyzing the electronic invoice according to the current state" as the system may 
provide a sort area to allow returned results to be sorted in ascending or descending 
order according to the following exemplary criteria: due date, invoice number, invoice 
date, purchase order number, net amount due, store or location number, and invoice 
aging (Ludwig Paragraph 0080). 

With respect to claim 12, Ludwig teaches "wherein the current state is 
selectable by the user according to predefinable events" as in this section, the 
system may permit biller system users to be associated with specific system events, 
which associations the system may be adapted to store as global information on the 
database. Any time one of these specific events occurs, the system may generate an 
automatic e-mail and send it to the selected list of biller system users. For example, 
exemplary distribution list choices may include: invoices loaded successfully, invoices 
loaded unsuccessfully, invoice adjusted, payment authorized, payment canceled, 
payment completed, and payment notification (Ludwig Paragraph 0104). The system 
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may only permit invoices with the status of "paid", "presented", or "viewed" to be closed. 
All other invoice states may indicate payer workflow is in progress, and the system may 
not permit invoices having such states to be closed (Ludwig Paragraph 0105). 

The system may permit a biller system user to select an option 605 to display 
invoices based on selected criteria and/or specify general search criteria for listing 
invoices. Depending on the selection, the system may direct the user to a "view 
options" page 606 for filtering and sorting (Ludwig Paragraph 0080). 

With respect to claim 13, Ludwig teaches "the method of claim 8, wherein the 
method is for use in business software, particularly in an enterprise resource 
planning software" as the business service provider system 16 may be an exchange 
or other service bureau application providing a plurality of business processing services 
to its clients (which may include the biller system 12 and/or payer system 14). One 
such business processing service may be electronic bill presentment and payment, as 
may be provided using a system and/or method consistent with the invention (Ludwig 
Paragraph 0027). 

Group of claims 14, 16, 18-19 and 20, 22, 24-25 are essentially the same as 
group of claims 8, 10, and 12-13 except they set forth the claimed invention as system 
and a computer-readable medium comprising instructions and are rejected for the same 
reasons as applied hereinabove. 
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With respect to claim 28, Ludwig teaches "an electronic data structure for an 
electronic data record according to any one of claims 1 and 3-7" as the exemplary 
embodiments of the system of the present invention described herein may be embodied 
as one or more distributed computer program processes, data structures (Ludwig 
Paragraph 0156). 

Claim 29 is essentially the same as claim 1 3 except it sets forth the claimed 
invention as an electronic data structure and is rejected for the same reason as applied 
hereinabove. 

Claims 3 and 5 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Ludwig et al. (U.S. PG Pub No. 2003/0004874) in view of Fa\k et al. (U. S. PG Pub No. 
2004/0111302) as applied to claims 1,6-8. 10, 12-14, 16, 18-20. 22, 24-25 and 28-29 
above further in view of Haseltine et al. (Haseltine hereinafter) (U. S. Patent No. 
6.578.015). 

With respect to claim 3, Ludwig teaches "the computer readable storage 
medium for storing electronic data record of claim 1, wherein the state value table 
comprises a description of the current state" as the system may link the status field 
to the invoice history page, at which the system may display a full status history for the 
selected invoice. By default, the system may display the following exemplary columns: 



Application/Control Number: Page 16 

10/770.423 

Art Unit: 2166 

payer name, invoice number, due date, status, net amount due, amount to pay, P.O. 
number, P.O. requisition number, store number, and select (Ludwig Paragraph 0092). 

Ludwig teaches the elements of claim 3 as noted above but does not explicitly 
discloses, "wherein the state value table comprises a description of the current 
state." 

However, Haseltine discloses, "wherein the state value table comprises a 
description of the current state" as a status table may be generated for the bill to 
Indicate the current status of the bill (Haseltine Col 3, Lines 41-43). 
Status tables 436 may also maintained in the active area 430 and may be viewed by 
customers. As the name implies, the status tables 436 track the status of the bills 
presented to the customers in the active area 430. For example, the status tables 436 
may track whether a customer's bills have been viewed, paid, have been submitted or 
are pending. Other indicia indicative of the status of the customers' bills may also be 
Included In the status tables 436 (Haseltine Col 6, Lines 11-20). 

It would have been obvious to one of ordinary skill In the art at the time the 
invention was made to combine the teaching of the cited references because 
Haseltine's teaching would have allowed Ludwig and Falk to allow customers to view 
and pay electronic bills in a flexible manner without the Involvement of paper bill and 
checks. 



With respect to claim 5, Ludwig teaches "the computer readable storage 
medium for storing electronic data record of claim 1, wherein the state value table 
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comprises an assignment of the current state to an event which can occur during 
the processing of the invoice" as in this section, the system may permit biller system 
users to be associated with specific system events, which associations the system may 
be adapted to store as global information on the database. Any time one of these 
specific events occurs, the system may generate an automatic e-mail and send it to the 
selected list of biller system users. For example, exemplary distribution list choices may 
include: invoices loaded successfully, invoices loaded unsuccessfully, invoice adjusted, 
payment authorized, payment canceled, payment completed, and payment notification 
(Ludwig Paragraph 0104). The system may only permit invoices with the status of 
"paid", "presented", or "viewed" to be closed. All other invoice states may indicate payer 
workflow is in progress, and the system may not permit invoices having such states to 
be closed (Ludwig Paragraph 0105). 

Ludwig teaches the elements of claim 5 as noted above but does not explicitly 
discloses, "the state value table comprises an assignment of the current state." 

However, Haseltine discloses, "the state value table comprises an 
assignment of the current state" as a status table may be generated for the bill to 
indicate the current status of the bill (Haseltine Col 3, Lines 41-43). Status tables 436 
may also maintained in the active area 430 and may be viewed by customers. As the 
name implies, the status tables 436 track the status of the bills presented to the 
customers in the active area 430. For example, the status tables 436 may track 
whether a customer's bills have been viewed, paid, have been submitted or are 
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pending. Other indicia indicative of the status of the customers' bills may also be 
included in the status tables 436 (Haseltine Col 6, Lines 11-20). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because 
Haseltine's teaching would have allowed Ludwig and Falk to allow customers to view 
and pay electronic bills in a flexible manner without the involvement of paper bill and 
checks. 

Response to Arguments 
Applicant's arguments have been considered but are moot in view of the. new 
ground(s) of rejection. 

In these arguments applicant relies on amended claims and not the original ones. 
See above rejections for response to the arguments. 

Claims must be given the broadest reasonable interpretation during examination 
and limitations appearing in the specification but not recited in the claim are not read 
into the claim (See M.P.E.P. 21 1 1 [R-l]). 

Conclusion 

Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 
§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 



Application/Control Number: Page 19 

10/770,423 

Art Unit: 2166 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

Contact Information 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Usmaan Saeed whose telephone number is (571)272-4046. 
The examiner can normally be reached on M-F 6-5. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hosain Alam can be reached on (571)272-3978. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from tlie Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more infomiation about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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